Data storage and format is ubiquitous with data management and data processing. In the context of computing applications, data is the lifeline. From simple content based data to complex embedded instruction sets, data acts as the input to most computing applications and is the resultant output of these computing applications. Not surprisingly, computing application designers and developers have developed staggering amounts of computing applications to create, manage, store, and process data that touches each of us in almost every aspect of our lives. From simple word processing applications to complicated encryption techniques for use in communicating sensitive data, data processing computing applications have become integrated within daily routines and practices. The development of the myriad of data operative computing applications has rendered an expected byproduct—simply a number of varying and disparate data formats and types.
With disparate data formats, it becomes increasingly difficult to share data between cooperating computing applications and computing environments that have their own native data formats and definitions. Addressing these concerns, computing application developers have developed and implemented various data filters and translators that allow them to accept non-native data formats. However, the integration and implementation of such data conversion mechanisms comes at an expense, namely, increased processing requirements and the loss of data integrity. Moreover, data conversion may not be available to each and every computing application seeking to process non-native data. As such, sharing desired data among cooperating computing applications is rendered difficult at best.
Data may be characterized by a rendering extension which is representative of the underlying format and/or layout. The rendering extension prompts cooperating applications of the data format and/or layout and, if appropriate, will trigger the conversion of data by the cooperating computing application to a native format native to the requesting cooperating computing application. The rendering extensions, generally, also provide an indication of which computing application or computing environment generated a piece or set of data. For example if a particular word processor computing application generated a data (e.g. a document), the rendering extension may be of the “.doc” variety. Comparatively, if a spreadsheet computing application generated some data (e.g. a spreadsheet, graph, etc.), then the rendering extension may be “.xls”.
Currently, computing applications generally generate data (e.g. reports) having a single rendering extension (e.g. html, .doc, .xls, .xml) definition that is usually native to the computing application that is generating the data. As such, cooperating applications, when processing reports, first are required to perform a translation of the foreign rendering extension to a native rendering extension. This translation step, in some instances, can introduce errors, that is, data layout/formatting error and, more importantly, data error. Moreover, the data, in such form, has limited utility to cooperating applications as the generated report is not easily queryable. In most instances, participating users will use the computing applications to generate new data having new report definitions instead of trying to reuse an already generated report.
Another drawback of existing practices is an inability to perform a time driven analysis of already generated data. As described, a computing application may operate on one or more cooperating data stores. These data stores have various tables having various field definitions. Over time the value of the fields will change to reflect one or more change in the organization and/or enterprise operating the data store. For example, a car dealership may employ a computing application cooperating with a data store to record sales. The sales values would change as more cars are sold. In the same example, the computing application may operate to generate a report to show the total sales by each of the sales staff of the car dealership. Once again with increasing sales, the report values change. Current data (e.g. report) generating computing applications operate such to gather the necessary data according to a definition and generate a data work product according to the report definition. However, the data work product acts a snapshot of the values of the data fields found in the cooperating data store at the time of the data work product generation.
Moreover, current computing applications would expose the generated data work product as data construct that is probably not schematized, not stored in a non-persistent data format, and thus is not easily queryable. As such, these applications would not be able to support a time-dimensioned query on the historical data work products to provide a time-driven analysis of one or more of the data values. By storing data in a non-persistent rendering dependent format, current applications are incapable of performing a time driven analysis that may be used to determine trends.
Rendering independent persistent data formats have many application outside of the report generation and management context. For example, a rendering independent persistent data format may be incorporated to communicate a variety of data, such as web content, across disparate computing application having their own native rendering requirements and standards.
From the foregoing it is appreciated that there exists a need for systems and methods that provides data in a rendering independent persistent format for use in a variety of processing that is not realized by current practices. By having these systems and methods the prior art is overcome.